feat(workspace): publish a locally-authored skill to the linked workspace - #1280

…pace (#1271)

The upload half of `skill-sync.ts`, which only ever pulls. A skill written locally
had no route to the workspace, and nothing in the CLI said so.

Shaped so agents and commands can ride the same path later: a workspace skill is a
named bundle of files, and nothing here is skill-specific except the endpoint it
posts to. `collectBundle` and the binary guard take a directory, not a skill.

Three rules the module exists to enforce, each a bug if skipped:

**Refuse non-UTF-8 files, naming the path.** The wire format is `{path, content}`
with content as a STRING — the server does `content.encode("utf-8")` inbound and
returns a decoded string outbound. A bundle carrying a PNG cannot round-trip: the
declared byte size stops matching after the re-encode and `skill-sync` skips the
whole skill, logging a warning nobody sees. Caught at publish it is one clear local
error; uncaught, the upload succeeds and the skill silently vanishes from every
OTHER machine, days later, with nothing tying symptom to cause. Decoding is strict
(`fatal: true`) because the default substitutes U+FFFD and would hand back a
"valid" string that reassembles into a different file.

**Never publish from the managed snapshot.** `.altimate-code/skill/_workspace`
holds skills the workspace sent us and sits under the same `{skill,skills}/**`
glob as the user's own — deliberately, since that is how they load. A publish that
walked "every skill in this project" would send the workspace's own skills back to
it. The check compares against a separator-terminated prefix, so `_workspace-notes`
is not mistaken for something inside `_workspace`.

**Remember the server's id, so a second publish updates.** Names are unique per
creator server-side, so a blind re-create answers 409 rather than duplicating — but
that turns an ordinary second publish into an error the user has to interpret.

The id lives in a local ledger, not `SKILL.md` frontmatter. Frontmatter is
committed, so the id would travel with the skill: a colleague cloning the repo and
publishing would UPDATE the original author's bundle rather than create their own.
It is keyed on the resolved directory and scoped to the account it was published
under, and rows are shape-checked on read rather than cast, so a corrupt entry
costs its own skill a re-create instead of a PATCH against a garbage id.

`privacy` is left unset — the server defaults to `private`. Publishing should
attach a skill to a workspace, not disclose it org-wide as a side effect of a
command whose name says nothing about visibility.

A 404 on update falls through to create: the skill was deleted in the workspace
since we published it, and failing would strand the user with a local id they can
neither see nor clear.

Tests: 11 new, 443 across `test/altimate/workspace`. Mutation-checked — 8
mutations, 8 killed: non-fatal decoding, dropping the managed-snapshot guard,
prefix-matching without the separator, always creating, swallowing the 409, not
re-creating after a 404, not recording the id, and defaulting privacy to public
each fail a test.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6

**A symlinked skill directory defeated the managed-snapshot check.**
`path.resolve` is lexical: it normalises `..` and absolutises, but it does not
follow links. So a skill directory that IS a link into `.altimate-code/skill/
_workspace` resolved to its own path, passed `isManagedSkill`, and the bundle
walk then followed the link — publishing the workspace's own skills back to it
under the user's name. Compared through `realpathSync` now, falling back to the
lexical form for a path that does not exist, which cannot be a link into the
snapshot anyway.

**The bundle size guard could not stop the thing it exists to stop.**
`collectBundle` read each file with `readFile` and only then checked the running
total, so a single oversized file was pulled entirely into memory before being
rejected. Size is checked before the read now; the cumulative check stays for
many small files and as a backstop if the file grows in between.

**A conflicting rename on the update path surfaced a raw API envelope.**
The POST path maps 409 to `SkillNameConflictError`; the PATCH path only handled
`NotFoundError`, so renaming a skill onto a name this creator already uses
reached the caller as the server's own error shape — the exact outcome the typed
errors in this module exist to prevent, and invisible from the create path.

Tests: 14 in this file, 3 new, whole altimate suite green.

Worth recording how the tests were arrived at, because the first versions were
worthless: all three mutations SURVIVED. Asserting that an oversized bundle is
rejected does not test this fix — the post-read check rejects it too — so the
test now patches `readFile` and asserts the oversized file is never read at all.
The other two had no coverage whatsoever. All three mutations fail now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6

…lise its writes

Two more from the cubic review on #1280. Both are the ledger describing
something other than what is actually on the server.

**One directory, two accounts, one id.** The ledger keyed on the resolved skill
directory alone, so publishing the same skill under a second account overwrote
the first account's record. Switching back found a row scoped to the other
tenant, treated the skill as unpublished, created it again — and 409'd on the
name that was already there, with the original id no longer reachable from this
machine. The key now carries tenant and API URL alongside the directory, so each
account keeps its own id. Reads still fall back to the old directory-only key,
so ids written by an earlier version are not stranded into a needless re-create;
the tenant check stays, because that fallback can return another account's row.

**Concurrent publishes dropped each other's ids.** Each publish read the whole
ledger, mutated its copy and wrote it back, so of two publishes in flight the
later write carried the earlier one away, and that skill created again on its
next run. Writes go through a promise chain now, and the re-read happens INSIDE
the chain — reusing a copy read before the previous write landed would lose it
just the same. Same shape `memory-index` already uses for the same reason.

Tests: 16 in this file, 2 new, whole altimate suite green (5799 tests).
Mutation-checked: keying by directory alone fails one, dropping the chain fails
four.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6

Creating a skill and attaching it to a workspace are two calls on the server,
and only the first was ever made. A skill that is created but attached to
nothing appears in no workspace: the CLI lists workspace skills with
`GET /skills?datamate_id=`, and so does the web UI. From the user's side,
"publish" had done nothing visible — the exact report from workspaces UAT that
this feature exists to close.

The binding is resolved BEFORE anything is uploaded, and an unlinked project is
refused with a typed `NotLinkedError`. Uploading first and failing to attach
would create precisely the orphan being fixed.

Attachment goes through `PUT /skills/{id}/datamates`, which REPLACES the whole
set. A bare put of one id would silently detach the skill from every other
workspace it is already on, so the current set is read from
`GET /skills/{id}` (`attached_datamate_ids`) and merged. Already attached: no
write.

Attached on the update path as well: a skill published before this project was
linked to its current workspace was otherwise refreshed but still absent from
it. On the create path the attach runs AFTER the id is recorded, so a failed
attach is retried by the next publish via the update path rather than creating
a second copy and 409ing on the name. `AttachFailedError` carries the id so the
caller can say exactly that.

`PublishReport` gains `datamateId`, so a caller can name the workspace it went
to. There is no caller yet — the command wiring is a follow-up — so no
error-mapping changes here.

Tests: 21 in the file, 5 new. Mutation-checked: never attaching on create,
dropping the merge, uploading while unlinked, and skipping the attach on update
each fail a test. Two existing tests needed the project linked under each
account they switch to, which is what a real account switch resolves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6

…t file is junk too

- `.ENV` and `.ENV.production` are the same file as `.env` on the
  case-insensitive file systems Windows and macOS default to, and slipped
  past a case-sensitive match.
- `git worktree add` leaves `.git` as a regular file, which the directory
  skip did not see.
- The update-path conflict test now actually renames: the second publish
  carries a new name, and the assertions pin that it went out as a PATCH
  rename rather than a create.

Verified: 506 pass across the workspace + plugin suites, typecheck clean.
Mutation-checked: dropping the case fold and dropping the `.git` file rule
each fail a test.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6

…e do not own, a ledger that survives key rotation

Ralph's review, verified against altimate-backend origin/development.

- `MAX_BUNDLE_FILES` is 100, the server's (`bundle.py:28`). At 200 a
  101–200 file bundle passed locally, uploaded in full, and was refused
  with a 400 — the case the constant exists to prevent. The ceiling is now
  checked before file 101 is opened.
- A project linked to a workspace the caller does not own is refused
  before anything is uploaded (`NotWorkspaceOwnerError`). Linking needs
  only visibility (`bind_existing`), attaching needs ownership
  (`_lock_workspaces`, 404 otherwise), so such a project created a skill
  the CLI could never attach — on every publish. The workspace list carries
  each owner and `GET /users/me` says who we are. When the list cannot say
  (an older server) and the attach 404s straight after a create, the skill
  just created is deleted and its id forgotten, so nothing is left behind.
- The ledger is scoped by user id (`GET /users/me`), not a digest of the
  API key: a rotated key made every published id on this machine
  unreachable, and the next publish created again — 409 on the name,
  "published from somewhere else". Rows carry `created_by`; a legacy row is
  trusted only once `GET /skills/{id}` confirms the skill is this user's,
  and is re-homed under the current key. All three earlier key shapes are
  still read.
- `.envrc` joins the junk list, and the list's comment says outright that
  it is a blocklist and therefore incomplete.

Verified: 511 pass across the workspace + plugin suites, typecheck clean.
Mutation-checked: the 200 ceiling, dropping the ownership pre-flight,
dropping the create-path compensation, keying on the digest, trusting a
legacy row without asking, and dropping `.envrc` each fail a test.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6